1. Field of the Invention
This invention relates to the field of multi-processing computers, multi-threaded computer systems development and run-time debugging. More specifically, the invention is a method and apparatus for run-time memory access checking of a target multi-threaded system.
2. Background
The invention described in this application is related to the debugger system described in U.S. Pat. No. 5,581,697 issued on Dec. 3, 1996, titled "Method and Apparatus for Run-Time Error Checking Using Dynamic Patching" by Wayne C. Gramlich, Sunnyvale, Calif.; Achut Reddy, San Jose, Calif.; and Shyam Desirazu, Foster City, Calif., and related to the system described in the U.S. Pat. No. 5,675,803 issued on Sep. 7, 1987 titled "Method & Apparatus for a Fast Debugger Fix & Continue Operation" by Thomas Preisler, Wayne C. Gramlich, Eduardo Pelegri-Llopart and Terrence Miller, both of which applications are hereby incorporated herein by reference.
The development of computer systems has progressed from traditional uni-processor systems to the use of systems with multiple central processor units (CPUs) in a given computer system. Such systems are designated "Multi-processor" hardware systems. Programming systems, including operating systems, have been designed to make use of multiple CPUs in a system by permitting application programs to be developed which use multiple threads which may be executed concurrently on the several CPUs. This requires additional control mechanisms to synchronize the different parts of an application which might be running simultaneously on two or more CPUs. Such new programing capabilities are generally embodied in the new programming paradigm called "multi-threading." A "thread of control" or more simply a "thread" is a sequence of instructions being executed in a program. A thread has a program counter (PC) and a stack to keep track of local variables and return addresses. Threads execute independently. Threads share the process instructions and most of its data, as well as share most of the operating system state of a process. Each thread may make arbitrary system calls. Threads and the associated control and services of a multithreaded system (including synchronization services) may be implemented as objects. Synchronization techniques which are implemented as objects include mutual exclusion (mutex) locks, semaphores, condition variables, and readers/writer locks. For more information on multithreads as applied to application programs, see the paper titled "SunOS Multi-thread Architecture" by M. L. Powell, S. R. Kleiman, S. Barton, D. Shah, D. Stein, M. Weeks, Proceedings of the USENIX Conference--Winter '91--Dallas, Tex. pages 65-79. See also the aforementioned text by Silbershatz et al, at pages 96-97, and 597-629.
Debugger programs written for uni-processor (i.e. single CPU) systems will generally not function correctly when testing application programs which are written to function in a multi-threaded mode. In the past, attempts have been made to develop debugging systems which check memory accesses during run-time but these debuggers are designed with uni-processor based application programs in mind. One such attempt was to interleave additional instructions adjacent to every memory access instruction in an object code module and then load and execute the augmented or new object code module in order to test the status of the addressed memory location during the execution of the augmented or new object code module. This method is used by the Purify program of Pure Software, Inc. which is described in U.S. Pat. Nos. 5,193,180 issued Mar. 9, 1993 and 5,335,344 issued Aug. 2, 1994. The Purify system reads object modules created by a compiler and interleaves instructions into the code of a target object module for every memory access instruction in the original object code module, thereby creating a new augmented object module which can then be linked to related object code and library modules and loaded into a computer and executed. This Purify approach is designed for single-threaded application programs and has been shown to incorrectly test a target application designed to be multi-threaded. This is due to the fact that each thread has its own Program Counter (PC) and stack and a debugger must be able to handle these separate stacks and report errors according to the particular thread which contained the error. Sun Microsystems, Inc., the assignee of this invention, has a run-time-checking feature in its dbx debugger Run-Time-Checking (RTC) system which is sold under the title of SPARCWorks, a collection of several developer tools. Unlike the Purify product, Sun's debugger product operates on a target application by loading the original object code module into a computer under the control of the debugger and starting a process reflecting the target application. If run-time-checking is requested by the user, the RTC section of the debugger overlays every memory reference instruction with a branch to instrumentation code and library modules designed to test the validity of memory locations being accessed. However this RTC system itself was originally designed to operate on single-threaded processes and it too requires modification to handle concurrently operating multiple threads with their individual stacks and program counters, etc. It is desirable that run-time debugging and especially memory access checking tools be available for multi-threaded application programs.
The present invention comprises a memory access checking system, designated Run Time Checking for Multi-Threaded applications (RTC/MT), which can test multi-threaded application programs, whether these application programs are tested on a uni-processor or on a multi-processor, and can correctly keep track of which thread of several possibly concurrently executing threads may encounter a memory access error, and can correctly report to the user the location in question and the thread attempting to access it.